<div class="tmd-doc">
<h1 class="tmd-header-1">
Type Embedding
</h1>
<p></p>
<div class="tmd-usual">
From the article <a href="struct.html">structs in Go</a>, we know that a struct type can have many fields. Each field is composed of one field name and one field type. In fact, sometimes, a struct field can be composed of a field type only. The way to declare struct fields is called type embedding.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
This article will explain the purpose of type embedding and all kinds of details in type embedding.
</div>
<p></p>
<h3 class="tmd-header-3">
What Does Type Embedding Look Like?
</h3>
<p></p>
<div class="tmd-usual">
Here is an example demonstrating type embedding:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "net/http"

func main() {
	type P = *bool
	type M = map[int]int
	var x struct {
		string // a named non-pointer type
		error  // a named interface type
		*int   // an unnamed pointer type
		P      // an alias of an unnamed pointer type
		M      // an alias of an unnamed type

		http.Header // a named map type
	}
	x.string = "Go"
	x.error = nil
	x.int = new(int)
	x.P = new(bool)
	x.M = make(M)
	x.Header = http.Header{}
}
</code></pre>
<p></p>
<div class="tmd-usual">
In the above example, six types are embedded in the struct type. Each type embedding forms an embedded field.
</div>
<p></p>
<div class="tmd-usual">
Embedded fields are also called as anonymous fields. However, each embedded field has a name specified implicitly. The <a href="https://golang.org/ref/spec#Qualified_identifiers">unqualified</a> type name of an embedded field acts as the name of the field. For example, the names of the six embedded fields in the above examples are <code class="tmd-code-span">string</code>, <code class="tmd-code-span">error</code>, <code class="tmd-code-span">int</code>, <code class="tmd-code-span">P</code>, <code class="tmd-code-span">M</code>, and <code class="tmd-code-span">Header</code>, respectively.
</div>
<p></p>
<p></p>
<h3 id="embeddable-types" class="tmd-header-3">
Which Types Can be Embedded?
</h3>
<p></p>
<div class="tmd-usual">
The current Go specification (version 1.25) <a href="https://golang.org/ref/spec#Struct_types">says</a>
</div>
<p></p>
<div class="tmd-quotation">
<div class="tmd-usual">
An embedded field must be specified as a type name <code class="tmd-code-span">T</code> or as a pointer to a non-interface type name <code class="tmd-code-span">*T</code>, and <code class="tmd-code-span">T</code> itself may not be a pointer type.
</div>
</div>
<p></p>
<p></p>
<div class="tmd-usual">
The above description was accurate before Go 1.9. However, with the introduction of type aliases in Go 1.9, the description <a href="https://github.com/golang/go/issues/22005">has become a little outdated and inaccurate</a>. For example, the description doesn't include the case of the <code class="tmd-code-span">P</code> field in the example in the last section.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
Here, the article tries to provide more accurate descriptions.
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
A type name <code class="tmd-code-span">T</code> can be embedded as an embedded field unless <code class="tmd-code-span">T</code> denotes a named pointer type or a pointer type whose base type is either a pointer or an interface type.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
A pointer type <code class="tmd-code-span">*T</code>, where <code class="tmd-code-span">T</code> is a type name denoting the base type of the pointer type, can be embedded as an embedded field unless type name <code class="tmd-code-span">T</code> denotes a pointer or interface type.
</div>
</li>
</ul>
<p></p>
<p></p>
<p></p>
<div class="tmd-usual">
The following lists some example types which can and can't be embedded:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">type Encoder interface {Encode([]byte) []byte}
type Person struct {name string; age int}
type Alias = struct {name string; age int}
type AliasPtr = *struct {name string; age int}
type IntPtr *int
type AliasPP = *IntPtr

// These types and aliases can be embedded.
Encoder
Person
*Person
Alias
*Alias
AliasPtr
int
*int

// These types and aliases can't be embedded.
AliasPP          // base type is a pointer type
*Encoder         // base type is an interface type
*AliasPtr        // base type is a pointer type
IntPtr           // named pointer type
*IntPtr          // base type is a pointer type
*chan int        // base type is an unmaed type
struct {age int} // unnamed non-pointer type
map[string]int   // unnamed non-pointer type
[]int64          // unnamed non-pointer type
func()           // unnamed non-pointer type
</code></pre>
<p></p>
<div class="tmd-usual">
No two fields are allowed to have the same name in a struct, there are no exceptions for anonymous struct fields. By the embedded field naming rules, an unnamed pointer type can't be embedded along with its base type in the same struct type. For example, <code class="tmd-code-span">int</code> and <code class="tmd-code-span">*int</code> can't be embedded in the same struct type.
</div>
<p></p>
<div class="tmd-usual">
A struct type can't embed itself or its aliases, recursively.
</div>
<p></p>
<div class="tmd-usual">
Generally, it is only meaningful to embed types who have fields or methods (the following sections will explain why), though some types without any field and method can also be embedded.
</div>
<p></p>
<h3 class="tmd-header-3">
What Is the Meaningfulness of Type Embedding?
</h3>
<p></p>
<div class="tmd-usual">
The main purpose of type embedding is to extend the functionalities of the embedded types into the embedding type, so that we don't need to re-implement the functionalities of the embedded types for the embedding type.
</div>
<p></p>
<div class="tmd-usual">
Many other object-oriented programming languages use inheritance to achieve the same goal of type embedding. Both mechanisms have their own <a href="https://en.wikipedia.org/wiki/Composition_over_inheritance">benefits and drawbacks</a>. Here, this article will not discuss which one is better. We should just know Go chose the type embedding mechanism, and there is a big difference between the two:
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
If a type <code class="tmd-code-span">T</code> inherits another type, then type <code class="tmd-code-span">T</code> obtains the abilities of the other type. At the same time, each value of type <code class="tmd-code-span">T</code> can also be viewed as a value of the other type.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
If a type <code class="tmd-code-span">T</code> embeds another type, then type other type becomes a part of type <code class="tmd-code-span">T</code>, and type <code class="tmd-code-span">T</code> obtains the abilities of the other type, but none values of type <code class="tmd-code-span">T</code> can be viewed as values of the other type.
</div>
</li>
</ul>
<p></p>
<p></p>
<div class="tmd-usual">
Here is an example to show how an embedding type extends the functionalities of the embedded type.
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

type Person struct {
	Name string
	Age  int
}
func (p Person) PrintName() {
	fmt.Println("Name:", p.Name)
}
func (p *Person) SetAge(age int) {
	p.Age = age
}

type Singer struct {
	Person // extends Person by embedding it
	works  []string
}

func main() {
	var gaga = Singer{Person: Person{"Gaga", 30}}
	gaga.PrintName() // Name: Gaga
	gaga.Name = "Lady Gaga"
	(&amp;gaga).SetAge(31)
	(&amp;gaga).PrintName()   // Name: Lady Gaga
	fmt.Println(gaga.Age) // 31
}
</code></pre>
<p></p>
<div class="tmd-usual">
From the above example, it looks that, after embedding type <code class="tmd-code-span">Person</code>, the type <code class="tmd-code-span">Singer</code> obtains all methods and fields of type <code class="tmd-code-span">Person</code>, and type <code class="tmd-code-span">*Singer</code> obtains all methods of type <code class="tmd-code-span">*Person</code>. Are the conclusions right? The following sections will answer this question.
</div>
<p></p>
<div class="tmd-usual">
Please note that, a <code class="tmd-code-span">Singer</code> value is not a <code class="tmd-code-span">Person</code> value, the following code doesn't compile:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">var gaga = Singer{}
var _ Person = gaga
</code></pre>
<p></p>
<h3 class="tmd-header-3">
Does the Embedding Type Obtain the Fields and Methods of the Embedded Types?
</h3>
<p></p>
<div class="tmd-usual">
Let's list all the fields and methods of type <code class="tmd-code-span">Singer</code> and the methods of type <code class="tmd-code-span">*Singer</code> used in the last example by using <a href="reflection.html">the reflection functionalities</a> provided in the <code class="tmd-code-span">reflect</code> standard package.
</div>
<p></p>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import (
	"fmt"
	"reflect"
)

... // the types declared in the last example

func main() {
	t := reflect.TypeOf(Singer{}) // the Singer type
	fmt.Println(t, "has", t.NumField(), "fields:")
	for i := 0; i &lt; t.NumField(); i++ {
		fmt.Print(" field#", i, ": ", t.Field(i).Name, "\n")
	}
	fmt.Println(t, "has", t.NumMethod(), "methods:")
	for i := 0; i &lt; t.NumMethod(); i++ {
		fmt.Print(" method#", i, ": ", t.Method(i).Name, "\n")
	}

	pt := reflect.TypeOf(&amp;Singer{}) // the *Singer type
	fmt.Println(pt, "has", pt.NumMethod(), "methods:")
	for i := 0; i &lt; pt.NumMethod(); i++ {
		fmt.Print(" method#", i, ": ", pt.Method(i).Name, "\n")
	}
}
</code></pre>
<p></p>
<div class="tmd-usual">
The result:
</div>
<pre class="tmd-code output">
main.Singer has 2 fields:
 field#0: Person
 field#1: works
main.Singer has 1 methods:
 method#0: PrintName
*main.Singer has 2 methods:
 method#0: PrintName
 method#1: SetAge
</pre>
<p></p>
<div class="tmd-usual">
From the result, we know that the type <code class="tmd-code-span">Singer</code> really owns a <code class="tmd-code-span">PrintName</code> method, and the type <code class="tmd-code-span">*Singer</code> really owns two methods, <code class="tmd-code-span">PrintName</code> and <code class="tmd-code-span">SetAge</code>. But the type <code class="tmd-code-span">Singer</code> doesn't own a <code class="tmd-code-span">Name</code> field. Then why is the selector expression <code class="tmd-code-span">gaga.Name</code> legal for a <code class="tmd-code-span">Singer</code> value <code class="tmd-code-span">gaga</code>? Please read the next section to get the reason.
</div>
<p></p>
<h3 id="shorten-form" class="tmd-header-3">
Shorthands of Selectors
</h3>
<p></p>
<div class="tmd-usual">
From the articles <a href="struct.html">structs in Go</a> and <a href="method.html">methods in Go</a>, we have learned that, for a value <code class="tmd-code-span">x</code>, <code class="tmd-code-span">x.y</code> is called a selector, where <code class="tmd-code-span">y</code> is either a field name or a method name. If <code class="tmd-code-span">y</code> is a field name, then <code class="tmd-code-span">x</code> must be a struct value or a struct pointer value. A selector is an expression, which represents a value. If the selector <code class="tmd-code-span">x.y</code> denotes a field, it may also has its own fields (if <code class="tmd-code-span">x.y</code> is a struct value) and methods. Such as <code class="tmd-code-span">x.y.z</code>, where <code class="tmd-code-span">z</code> can also be either a field name or a method name.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
In Go, (without considering selector colliding and shadowing explained in a later section), <span class="tmd-bold"><span class="tmd-italic">if a middle name in a selector corresponds to an embedded field, then that name can be omitted from the selector</span></span>. This is why embedded fields are also called anonymous fields.
</div>
<p></p>
<div class="tmd-usual">
For example:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

type A struct {
	FieldX int
}

func (a A) MethodA() {}

type B struct {
	*A
}

type C struct {
	B
}

func main() {
	var c = &amp;C{B: B{A: &amp;A{FieldX: 5}}}

	// The following 4 lines are equivalent.
	_ = c.B.A.FieldX
	_ = c.B.FieldX
	_ = c.A.FieldX // A is a promoted field of C
	_ = c.FieldX   // FieldX is a promoted field

	// The following 4 lines are equivalent.
	c.B.A.MethodA()
	c.B.MethodA()
	c.A.MethodA()
	c.MethodA() // MethodA is a promoted method of C
}
</code></pre>
<p></p>
<div class="tmd-usual">
This is why the expression <code class="tmd-code-span">gaga.Name</code> is legal in the example in the last section. For it is just the shorthand of <code class="tmd-code-span">gaga.Person.Name</code>.
</div>
<p></p>
<div class="tmd-usual">
Similarly, the selector <code class="tmd-code-span">gaga.PrintName</code> can be viewed as a shorthand of <code class="tmd-code-span">gaga.Person.PrintName</code>. But, it is also okay if we think it is not a shorthand. After all, the type <code class="tmd-code-span">Singer</code> really has a <code class="tmd-code-span">PrintName</code> method, though the method is declared implicitly (please read the section after next for details). For the similar reason, the selector <code class="tmd-code-span">(&amp;gaga).PrintName</code> and <code class="tmd-code-span">(&amp;gaga).SetAge</code> can also be viewed as, or not as, shorthands of <code class="tmd-code-span">(&amp;gaga.Person).PrintName</code> and <code class="tmd-code-span">(&amp;gaga.Person).SetAge</code>.
</div>
<p></p>
<div class="tmd-usual">
<code class="tmd-code-span">Name</code> is called a promoted field of type <code class="tmd-code-span">Singer</code>. <code class="tmd-code-span">PrintName</code> is called a promoted method of type <code class="tmd-code-span">Singer</code>.
</div>
<p></p>
<div class="tmd-usual">
Note, we can also use the selector <code class="tmd-code-span">gaga.SetAge</code>, only if <code class="tmd-code-span">gaga</code> is an addressable value of type <code class="tmd-code-span">Singer</code>. It is just syntactical sugar of <code class="tmd-code-span">(&amp;gaga).SetAge</code>. Please read <a href="method.html#call">method calls</a> for details.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
In the above examples, <code class="tmd-code-span">c.B.A.FieldX</code> is called the full form of selectors <code class="tmd-code-span">c.FieldX</code>, <code class="tmd-code-span">c.B.FieldX</code> and <code class="tmd-code-span">c.A.FieldX</code>. Similarly, <code class="tmd-code-span">c.B.A.MethodA</code> is called the full form of selectors <code class="tmd-code-span">c.MethodA</code>, <code class="tmd-code-span">c.B.MethodA</code> and <code class="tmd-code-span">c.A.MethodA</code>.
</div>
<p></p>
<div class="tmd-usual">
If every middle name in the full form of a selector corresponds to an embedded field, then the number of middle names in the selector is called the depth of the selector. For example, the depth of the selector <code class="tmd-code-span">c.MethodA</code> used in an above example is <span class="tmd-italic">2</span>, for the full form of the selector is <code class="tmd-code-span">c.B.A.MethodA</code>.
</div>
<p></p>
<h3 id="selector-shadow-and-collide" class="tmd-header-3">
Selector Shadowing and Colliding
</h3>
<p></p>
<div class="tmd-usual">
For a value <code class="tmd-code-span">x</code> (we should always assume it is addressable, even if it is not), it is possible that many of its full-form selectors have the same last item <code class="tmd-code-span">y</code> and every middle name of these selectors represents an embedded field. For such cases,
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
only the full-form selector with the shallowest depth (assume it is the only one) can be shortened as <code class="tmd-code-span">x.y</code>. In other words, <code class="tmd-code-span">x.y</code> denotes the full-form selector with the shallowest depth. Other full-form selectors are <span class="tmd-bold">shadowed</span> by the one with the shallowest depth.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
if there are more than one full-form selectors with the shallowest depth, then none of those full-form selectors can be shortened as <code class="tmd-code-span">x.y</code>. We say those full-form selectors with the shallowest depth are <span class="tmd-bold">colliding</span> with each other.
</div>
</li>
</ul>
<p></p>
<div class="tmd-usual">
If a method selector is shadowed by another method selector, and the two corresponding method signatures are identical, we say the first method is overridden by the other one.
</div>
<p></p>
<div class="tmd-usual">
For example, assume <code class="tmd-code-span">A</code>, <code class="tmd-code-span">B</code> and <code class="tmd-code-span">C</code> are three <a href="type-system-overview.html#type-definition">defined types</a>.
</div>
<p></p>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">type A struct {
	x string
}
func (A) y(int) bool {
	return false
}

type B struct {
	y bool
}
func (B) x(string) {}

type C struct {
	B
}
</code></pre>
<p></p>
<div class="tmd-usual">
The following code doesn't compile. The reason is the depths of the selectors <code class="tmd-code-span">v1.A.x</code> and <code class="tmd-code-span">v1.B.x</code> are equal, so the two selectors collide with each other and neither of them can be shortened to <code class="tmd-code-span">v1.x</code>. The same situation is for the selectors <code class="tmd-code-span">v1.A.y</code> and <code class="tmd-code-span">v1.B.y</code>.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">var v1 struct {
	A
	B
}

func f1() {
	_ = v1.x // error: ambiguous selector v1.x
	_ = v1.y // error: ambiguous selector v1.y
}
</code></pre>
<p></p>
<div class="tmd-usual">
The following code compiles okay. The selector <code class="tmd-code-span">v2.C.B.x</code> is shadowed by <code class="tmd-code-span">v2.A.x</code>, so the selector <code class="tmd-code-span">v2.x</code> is a shortened form of <code class="tmd-code-span">v2.A.x</code> actually. For the same reason, the selector <code class="tmd-code-span">v2.y</code> is a shortened form of <code class="tmd-code-span">v2.A.y</code>, not of <code class="tmd-code-span">v2.C.B.y</code>.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">var v2 struct {
	A
	C
}

func f2() {
	fmt.Printf("%T \n", v2.x) // string
	fmt.Printf("%T \n", v2.y) // func(int) bool
}
</code></pre>
<p></p>
<div class="tmd-usual">
Colliding or shadowed selectors don't prevent their deeper selectors being promoted. For example, the <code class="tmd-code-span">.M</code> and <code class="tmd-code-span">.z</code> selectors still get promoted in the following example.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

type x string
func (x) M() {}

type y struct {
	z byte
}

type A struct {
	x
}
func (A) y(int) bool {
	return false
}

type B struct {
	y
}
func (B) x(string) {}

func main() {
	var v struct {
		A
		B
	}
	//_ = v.x // error: ambiguous selector v.x
	//_ = v.y // error: ambiguous selector v.y
	_ = v.M // ok. &lt;=&gt; v.A.x.M
	_ = v.z // ok. &lt;=&gt; v.B.y.z
}
</code></pre>
<p></p>
<div class="tmd-usual">
One detail which is unusual but should be noted is that two unexported methods (or fields) from two different packages are always viewed as two different identifiers, even if their names are identical. So they will not never collide with or shadow each other when their owner types are embedded in the same struct type. For example, a program comprising two packages as the following shows will compile and run okay. But if all the <code class="tmd-code-span">m()</code> occurrences are replaced with <code class="tmd-code-span">M()</code>, then the program will fail to compile for <code class="tmd-code-span">A.M</code> and <code class="tmd-code-span">B.M</code> collide with each other, so <code class="tmd-code-span">c.M</code> is not a valid selector.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package foo // import "x.y/foo"

import "fmt"

type A struct {
	n int
}

func (a A) m() {
	fmt.Println("A", a.n)
}

type I interface {
	m()
}

func Bar(i I) {
	i.m()
}
</code></pre>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"
import "x.y/foo"

type B struct {
	n bool
}

func (b B) m() {
	fmt.Println("B", b.n)
}

type C struct{
	foo.A
	B
}

func main() {
	var c C
	c.m()      // B false
	foo.Bar(c) // A 0
}
</code></pre>
<p></p>
<h3 class="tmd-header-3">
Implicit Methods for Embedding Types
</h3>
<p></p>
<div class="tmd-usual">
As mentioned above, both of type <code class="tmd-code-span">Singer</code> and type <code class="tmd-code-span">*Singer</code> have a <code class="tmd-code-span">PrintName</code> method each, and the type <code class="tmd-code-span">*Singer</code> also has a <code class="tmd-code-span">SetAge</code> method. However, we never explicitly declare these methods for the two types. Where do these methods come from?
</div>
<p></p>
<div class="tmd-usual">
In fact, assume a struct type <code class="tmd-code-span">S</code> embeds a type (or a type alias) <code class="tmd-code-span">T</code> and the embedding is legal,
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
for each method of the embedded type <code class="tmd-code-span">T</code>, if the selectors to that method neither collide with nor are shadowed by other selectors, then compilers will implicitly declare a corresponding method with the same specification for the embedding struct type <code class="tmd-code-span">S</code>. And consequently, compilers will also <a href="method.html#implicit-pointer-methods">implicitly declare a corresponding method</a> for the pointer type <code class="tmd-code-span">*S</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
for each method of the pointer type <code class="tmd-code-span">*T</code>, if the selectors to that method neither collide with nor are shadowed by other selectors, then compilers will implicitly declare a corresponding method with the same specification for the pointer type <code class="tmd-code-span">*S</code>.
</div>
</li>
</ul>
<p></p>
<p></p>
<div class="tmd-usual">
Simply speaking,
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
type <code class="tmd-code-span">struct{Embedded}</code> and type <code class="tmd-code-span">*struct{Embedded}</code> (if they are valid) both obtain all the methods of the type denoted by <code class="tmd-code-span">Embedded</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
type <code class="tmd-code-span">*struct{Embedded}</code>, type <code class="tmd-code-span">struct{*Embedded}</code>, and type <code class="tmd-code-span">*struct{*Embedded}</code> (if they are valid) all obtain all the methods of type <code class="tmd-code-span">*Embedded</code>.
</div>
</li>
</ul>
<p></p>
<div class="tmd-usual">
The following (promoted) methods are implicitly declared by compilers for type <code class="tmd-code-span">Singer</code> and type <code class="tmd-code-span">*Singer</code>.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">// Note: these declarations are not legal Go syntax.
// They are shown here just for explanation purpose.
// They indicate how implicit method values are
// evaluated (see the next section for more).
func (s Singer) PrintName = s.Person.PrintName
func (s *Singer) PrintName = (*s).Person.PrintName
func (s *Singer) SetAge = (&amp;(*s).Person).SetAge
</code></pre>
<p></p>
<div class="tmd-usual">
The right parts are the corresponding full form selectors.
</div>
<p></p>
<div class="tmd-usual">
From the article <a href="method.html">methods in Go</a>, we know that we can't explicitly declare methods for unnamed struct types and unnamed pointer types whose base types are unnamed struct types. But through type embedding, such unnamed types can also own methods.
</div>
<p></p>
<p></p>
<p></p>
<div class="tmd-usual">
If a struct type embeds a type which implements an interface type (the embedded type may be the interface type itself), then generally the struct type also implements the interface type, exception there is a method specified by the interface type shadowed by or colliding other methods or fields. For example, in the above example program, both the embedding struct type and the pointer type whose base type is the embedding struct type implement the interface type <code class="tmd-code-span">I</code>.
</div>
<p></p>
<div class="tmd-usual">
Please note, a type will only obtain the methods of the types it embeds directly or indirectly. In other words, the method set of a type is composed of the methods declared directly (either explicitly or implicitly) for the type and the method set of the type's underlying type. For example, in the following code,
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
the type <code class="tmd-code-span">Age</code> has no methods, for it doesn't embed any types.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
the type <code class="tmd-code-span">X</code> has two methods, <code class="tmd-code-span">IsOdd</code> and <code class="tmd-code-span">Double</code>. <code class="tmd-code-span">IsOdd</code> is obtained by embedding the  type <code class="tmd-code-span">MyInt</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
the type <code class="tmd-code-span">Y</code> has no methods, for its embedded the type <code class="tmd-code-span">Age</code> has not methods.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
the type <code class="tmd-code-span">Z</code> has only one method, <code class="tmd-code-span">IsOdd</code>, which is obtained by embedding the type <code class="tmd-code-span">MyInt</code>. It doesn't obtain the method <code class="tmd-code-span">Double</code> from the type <code class="tmd-code-span">X</code>, for it doesn't embed the type <code class="tmd-code-span">X</code>.
</div>
</li>
</ul>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">type MyInt int
func (mi MyInt) IsOdd() bool {
	return mi%2 == 1
}

type Age MyInt

type X struct {
	MyInt
}
func (x X) Double() MyInt {
	return x.MyInt + x.MyInt
}

type Y struct {
	Age
}

type Z X
</code></pre>
<p></p>
<h3 id="method-value-evaluation" class="tmd-header-3">
Normalization and Evaluation of Promoted Method Values
</h3>
<p></p>
<div class="tmd-usual">
Assume <code class="tmd-code-span">v.m</code> is a legal promoted method value expression, compilers will normalize it as the result of changing implicit address taking and pointer dereference operations into explicit ones in the corresponding full form selector of <code class="tmd-code-span">v.m</code>.
</div>
<p></p>
<div class="tmd-usual">
The same as any other <a href="method.html#method-value-evaluation">method value evaluation</a>, for a normalized method value expression <code class="tmd-code-span">v.m</code>, at run time, when the method value <code class="tmd-code-span">v.m</code> is evaluated, the receiver argument <code class="tmd-code-span">v</code> is evaluated and a copy of the evaluation result is saved and used in later calls to the method value.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
For example, in the following code
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
the full form selector of the promoted method expression <code class="tmd-code-span">s.M1</code> is <code class="tmd-code-span">s.T.X.M1</code>. After changing the implicit address taking and pointer dereference operations in it, it becomes <code class="tmd-code-span">(*s.T).X.M1</code>. At run time, the receiver argument <code class="tmd-code-span">(*s.T).X</code> is evaluated and a copy of the evaluation result is saved and used in later calls to the promoted method value. The evaluation result is <code class="tmd-code-span">1</code>, that is why the call <code class="tmd-code-span">f()</code> always prints <code class="tmd-code-span">1</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
the full form selector of the promoted method expression <code class="tmd-code-span">s.M2</code> is <code class="tmd-code-span">s.T.X.M2</code>. After changing the implicit address taking and pointer dereference operations in it, it becomes <code class="tmd-code-span">(&amp;(*s.T).X).M2</code>. At run time, the receiver argument <code class="tmd-code-span">&amp;(*s.T).X</code> is evaluated and a copy of the evaluation result is saved and used in later calls to the promoted method value. The evaluation result is the address of the field <code class="tmd-code-span">s.X</code> (a.k.a. <code class="tmd-code-span">(*s.T).X</code>). Any change of the value <code class="tmd-code-span">s.X</code> will be reflected through the dereference of the address, but the changes of the value <code class="tmd-code-span">s.T</code> have no effects on the evaluation result, that is why the two <code class="tmd-code-span">g()</code> calls both print <code class="tmd-code-span">2</code>.
</div>
</li>
</ul>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

type X int

func (x X) M1() {
	fmt.Println(x)
}

func (x *X) M2() {
	fmt.Println(*x)
}

type T struct { X }

type S struct { *T }

func main() {
	var t = &amp;T{X: 1}
	var s = S{T: t}
	var f = s.M1 // &lt;=&gt; (*s.T).X.M1
	var g = s.M2 // &lt;=&gt; (&amp;(*s.T).X).M2
	s.X = 2
	f() // 1
	g() // 2
	s.T = &amp;T{X: 3}
	f() // 1
	g() // 2
}
</code></pre>
<p></p>
<h3 class="tmd-header-3">
Interface Types Embed All Kinds of Types
</h3>
<p></p>
<div class="tmd-usual">
Interface types can embed all kinds of types. Please read <a href="interface.html">interfaces in Go</a> for details.
</div>
<p></p>
<p></p>
<p></p>
<h3 id="dead-loop-example" class="tmd-header-3">
An Interesting Type Embedding Example
</h3>
<p></p>
<div class="tmd-usual">
In the end, let's view an interesting example. The example program will dead loop and stack overflow. If you have understood the above contents and <a href="interface.html#polymorphism">polymorphism</a> and type embedding, it is easy to understand why it will dead loop.
</div>
<p></p>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

type I interface {
	m()
}

type T struct {
	I
}

func main() {
	var t T
	var i = &amp;t
	t.I = i
	i.m() // will call t.m(), then call i.m() again, ...
}
</code></pre>
<p></p>
</div>
